Auth0のproduction checks suiteを実行して本番環境で使用できる状態か確認する
アプリケーションを本番環境にデプロイする前、手動であれ自動であれ必ず本番にデプロイしても大丈夫かチェック/テストするかと思います。
Auth０を使う場合、アプリケーションに必要な設定をほとんどGUI上で行うことができ非常に便利ですが、その設定を使って本番環境で動かして大丈夫かどうか確認したいことがありますよね。
Auth0では、production checks suiteという機能が用意されており、 それを使ってテナントが本番環境で使用できる状態であることを確認することが可能です。
今回は実際にチェックを実行して内容を確認していきたいと思います。
Howto
チェックを行うには、 Auth0サポートセンターテナントセクション にアクセスします。
Auth0にログインしていない場合はログインします。
ナビゲーションバーにあるテナントをクリックすると、以下のようにテナント一覧が表示されます。
テナントがボックス表示で分けられています。checkしたいテナントの歯車マーク(右上)をクリックします。
Run Production Checkをクリックすると、checkツールのページに遷移します。
Select Applicationsでテナントに紐づいている複数のアプリケーションを選択できます。
今回は1つを選択して実行します。
RUN CHECKボタンを押すとチェックが始まります。
実行が終わると結果が表示されます。
production checks suiteの実行はこれで完了になります。
Required, Recommended, Best Practices とタブが分けられていて、数も表示されていますね。
この数はcheckに失敗した数です。下にcheck項目と詳細情報などが表示されています。
では、check項目の結果、内容などをみていきます。
チェック結果について
結果のタイプには Required, Recommended, Best Practices の3つがあります。
Required
本番環境にデプロイする前に完了するステップがないかどうかのチェック。ステップがあるとエラーが表示されます。
Support Email is configured
テナント設定でサポート用のEmailアドレスが設定されているかどうかの確認。
Support URL is configured
テナント設定でサポート用のURLが設定されているかどうかの確認。
Email Provider is configured
カスタム電子メールプロバイダーが構成されているかどうかの確認。
Allowed Web Origins are not Localhost
許可されたWeb Origins URLがlocalhost(http://localhost:3000のような)を指していないことを検証
Allowed Callback URLs are not Localhost
アプリケーションの許可されたコールバックURLがlocalhost、127.0.0.1などを指していないことを検証
Allowed Origins (CORS) is not Localhost
ページのロケーションURLがlocalhostを指していないことを検証
Tenant Environment Tag is configured
テナント環境タグが本番、ステージングまたは開発のいずれかに適切に設定されていることを確認
Social Connections are not using Auth0 Developer Keys
Social ConnectionsがデフォルトのAuth0開発者キーを使用していないことを確認
Guardian SMS Provider is configured
Guardian Multifactor Authenticationを使用している場合、Twilio SMSプロバイダーが設定されていることを確認
Legacy User Profile is disabled
レガシーユーザープロファイルトグルがオフになっていることを確認
Allow ID Tokens for Management API v2 Authentication is disabled
「management API v2認証のIDトークンを許可する」トグルがオフになっていることを確認
Recommended
Auth0が推奨するステップがないかどうかが確認されます。提案された手順を完了する必要はありませんが、少なくとも結果を確認して、実装に役立つかどうかを確認することをお勧めします
Custom Error Page is configured
アプリケーションの詳細と企業ブランドを使用してカスタムエラーページを構成することを推奨
Password Reset Page is customized
アプリケーションの詳細と企業ブランドを使用して、パスワードリセット用のカスタムホストページを構成することを推奨
Guardian Multifactor Page is customized
Guardian Multifactor Authenticationを使用している場合は、アプリケーションの詳細と企業ブランドを使用して、Guardian Multifactorのカスタムホストページを構成することを推奨
Custom Domain is configured
ユニバーサルログインでカスタムドメインを使用することを推奨
Guardian Multifactor or other Multifactor Authentication Providers
認証戦略の一部として多要素認証を検討することを推奨
Redirect Logout URL
許可されたリダイレクトログアウトURLを確認することを推奨
MFA for Tenant Administrators is enabled
テナント管理者は多要素認証を有効にすることを推奨
Use RS256 Instead of HS256
JsonWebToken Signature AlgorithmはHS256 over RS256に設定することを推奨
Email Templates are configured
アプリケーション固有の詳細と企業ブランドでカスタム電子メールテンプレートを構成することを推奨
Best Practices
Auth0が自動チェックを使用できない領域です。懸念される可能性のある領域を一覧表示します。実装を確認して、Auth0の推奨事項に準拠しているかどうかを確認することをお勧めします。
Tenants and Administrators
すべてのテナントとテナント管理者を確認し、それらが正しいことを確認します。 使用されなくなった廃止テナント。テナント管理者が必要なユーザーに限定されていることを確認
SSO Timeout Values
デフォルトのSSO Cookieタイムアウト値を確認し、要件に合っていることを確認
Verify Client Ids in App Code
アプリケーションコード内で、クライアントIDがAuth0アプリケーション構成と整合していることを確認
Whitelist Auth0 Public IPs
ルール、フック、またはカスタムデータベース内から内部サービスまたはファイアウォールサービスに接続している場合、Auth0 IPがホワイトリストに登録されていることを確認
Anomaly Detection
Auth0異常検出機能と構成を確認することを推奨
Externalize Configuration Parameters
ルール、フック、またはカスタムデータベース接続を開発するときは、資格情報、接続文字列、APIキーなどをルールにハードコードするのではなく、構成パラメーターに外部化することを推奨
本番デプロイする前には必ずチェックしよう
タイプがRequiredのものは必ず通しましょう。
Recommendedのものも通した方が良いですね。
ベストプラクティスとどれだけ離れているかの目安となるよう、Best Practicesのものも確認した方が良いと思います。
また、Auth0でチェックリストのエクセルも提供されているので、システムのニーズに合わせてカスタマイズしていくことも良いと思います。
![[Auth0] Auth0+Amazon EventBridge+AWS Lambda+New Relicで認証・認可のログを自動分析、可視化できるようにしてみた [New Relic]](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e37cf03c5caac969de0f633e4738977d/1862834d1806cb03b64a8000a5a1a39e/Auth0ByOkta.jpg)
